(1) Field of the Invention
The present invention is directed to mobile communications, more particularly to mobile Internet communications.
(2) Description of the Related Art
The Internet Protocol (“IP” or “TCP/IP”) has become the de facto standard for most network communication. The earliest networks required all the devices be connected to each other by wired connections, and the device needed an IP address that uniquely identified the device's point of attachment to the Internet. The device was required to be located on the network indicated by its IP address in order to receive datagrams destined to it; otherwise, datagrams destined to the device would be undeliverable. For a device to change its point of attachment without losing its ability to communicate, the device either had to change its IP address whenever it changed its point of attachment, or host-specific routes had to be propagated throughout much of the Internet routing fabric. Furthermore, because IP unlike other networking protocols such as IPX, needs addresses and configuration settings to be defined on each device on the network, there may be an immense amount of system administration work.
The Dynamic Host Configuration Protocol (“DHCP”) was developed to ease the amount of work and administration required to manage IP networks. DHCP allowed “pools” of TCP/IP addresses to be assigned to a DHCP server which are then allocated to client devices by the DHCP server. The pools are called scopes in DHCP terminology. Furthermore, DHCP not only assigned TCP/IP addresses, but also enabled required configuration settings such as subnet, mask, default router, and DNS server which are required for TCP/IP to work properly to be set. DHCP works across most routers and allocates IP addresses according to the subnet where the request initiated, eliminating the need to re-configure a device that moved from one subnet to another. Another feature of DHCP is that addresses can be leased for periods of time. When the address expires, the device may either request a renewal, otherwise, the IP address is put back into the pool of unallocated addresses which helps to recover unused IP addresses.
The procedure for using DHCP is quite simple. When a DHCP client is first switched on, it sends a broadcast packet on the network with a DHCP request. This is picked up by a DHCP server, which allocates an IP address to the device from one of the scopes (the pools of addresses) it has available.
Each DHCP scope is used for a different TCP/IP network segment. On net-works with routers that support DHCP, extra information is added to the request by the router to tell the server which network the request came from. The DHCP server uses this information to pick an address from the correct scope. The server replies to the client, allocating it the TCP/IP address and settings required.
However, DHCP doesn't allocate the address permanently. It tells the client that it has “leased” the address to it for a specific time period, which the administrator can control. By default DHCP is installed with a three-day lease period. When the lease expires, the client can ask the server to renew the lease. If the DHCP server doesn't hear from the client beyond the expiration of the lease period, it will put that address back in the pool ready to be re-used.
Recently, mobile, usually wireless, devices have gained popularity. It is desired that these devices also use the IP protocol. Because mobile devices change locations, the device may be located on either its home or a foreign network. Presently, each mobile device is always identified by its home address, regardless of its current point of attachment to the Internet. A standard protocol, Mobile IP, is used to forward IP packets between a mobile host on a foreign network and the home network for the mobile host. While situated away from its home network, a mobile device is associated with a care-of address, which provides information about its current point of attachment to the Internet.
A mobile host that boots on its home subnet can use DHCP to obtain a home IP address on its home subnet. By default, a DHCP server will allocate an IP address for the subnet where a DHCP request originates. Therefore, a mobile host that boots on a foreign subnet cannot simply broadcast a DHCP request on the local subnet to obtain an IP address for its home subnet. Standard Mobile IP requires that a mobile host must have a permanent IP address for its home subnet. Therefore, a mobile host, without an IP address, cannot use Mobile IP to forward a DHCP request to a DHCP server on its home subnet because it does not have a home IP address. Therefore, a mobile device cannot use DHCP when booting on a foreign network. Thus, the need exists for a mobile host to be able to access a DHCP server on its home network from a foreign network to obtain its home address.
In one proposed solution a mobile host can send a Mobile IP Registration Request, with a “home address” of zero to a “home agent” on its home subnet, obtain a “temporary home IP address” from the home agent and then send inbound requests to the home DHCP server, therefore the home DHCP server services the request. The solution assumes that the corresponding DHCP Reply will be sent to a broadcast MAC address (i.e. Ethernet address). However, the DHCP standard recommends that a DHCP reply be sent to a unicast MAC address. A Mobile IP home agent in a router can only receive frames with the unicast destination 802 address of the router interface. Therefore, a DHCP Reply with a unicast 802 destination address cannot be forwarded to the mobile host by the home agent.
A proposed solution for the previous problem has been to enter the temporary IP address assigned to the mobile host into the giaddr field of a DHCP request. However, this proposal is in conflict with current DHCP/BOOTP forwarding rules. BOOTP rules require that when a BOOTP relay agent receives a request, if the giaddr field is zero, the BOOTP relay agent inserts its address and then forwards the request; however, if the giaddr field is nonzero, the BOOTP relay agent cannot forward the request. Therefore, this proposed solution will not work because the BOOTP relay agent cannot forward a BOOTP or DHCP request with a nonzero giaddr field.
Additional objects, advantages and novel features of the invention will be set forth in part in the description which follows, and in part will become apparent to those skilled in the art upon examination of the following or may be learned by practice of the invention.